home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000245_connolly@pixel.convex.com _Thu Oct 22 02:11:16 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  9KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA07854; Thu, 22 Oct 92 02:11:16 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA28764; Thu, 22 Oct 92 02:11:01 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA07818; Wed, 21 Oct 92 20:09:55 -0500
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA02869; Wed, 21 Oct 92 20:09:36 -0500
  10. Message-Id: <9210220109.AA02869@pixel.convex.com>
  11. To: gopher@boombox.micro.umn.edu, wais-talk@quake.think.com,
  12.         www-talk@nxoc01.cern.ch
  13. Cc: nsb@bellcore.com
  14. Subject: misconceptions about MIME [long]
  15. Summary: MIME body != MIME message, MIME is for 8bit systems too
  16. Content-Type: multipart/mixed; boundary="cut"
  17. Date: Wed, 21 Oct 92 20:09:36 CDT
  18. From: Dan Connolly <connolly@pixel.convex.com>
  19.  
  20. --cut
  21.  
  22. I wrote an article a while back called "MIME for global hypertext." It
  23. was about a world where all the information tools on the internet
  24. interoperated, with MIME as the substrate. Since then, I've got a few
  25. words of support, but none from the important people. It seems that
  26. many people have taken a cursory look at MIME and dismissed it as only
  27. relevant to email.
  28.  
  29.  
  30.     BODY PARTS AND MESSAGES
  31.  
  32. There are two misconceptions about MIME that show up frequently in
  33. response to my suggestions. The first is the confusion between a MIME
  34. body part and MIME message.
  35.  
  36. A MIME body part is just a sequence of bytes with an associated
  37. content-type and content-transfer-encoding -- much like a C variable
  38. is just a piece of memory with an associated type. The default MIME
  39. content-type is text/plain, i.e. a sequence of lines of text.
  40.  
  41. So all the text files out there in the world already fit the role of a
  42. MIME body part. They don't need any headers, encodings, or anything.
  43. In fact, all the non text files qualify as MIME body parts too, if we
  44. associate them with the application/octet-stream content-type and the
  45. binary content-transfer-encoding.
  46.  
  47. A MIME message is actually a special case of the body part concept.
  48. Along with the text/plain, image/gif, audio/basic,
  49. application/postscript etc. types, there's a message/rfc-822 type.
  50. That's where the headers and stuff come in.
  51.  
  52. There's also a multipart/mixed type that encapsulates several body
  53. parts into one. It has some syntax that a lot of folks aren't crazy
  54. about, but it's just _one_type_ of body part.
  55.  
  56.  
  57.     EIGHT BIT DATA, ENCODINGS, AND TRANSPORT
  58.  
  59. The other area of confusion concerns eight bit data. MIME provides
  60. mechanisms for transport of eight bit data across mail transport
  61. agents that only grok limited character sets and line lengths. These
  62. mechanisms obviously increase the size of messages.
  63.  
  64. But when used with 8-bit-clean transport mechanisms, the encodings are
  65. not necessary, and MIME adds no cost to data transport. From the RFC:
  66.  
  67.     As of the publication of this document, there are no
  68.     standardized Internet transports for which it is legitimate
  69.         to include unencoded 8-bit or binary data in mail bodies.
  70.         Thus there are no circumstances in which the "8bit" or "binary"
  71.         Content-Transfer-Encoding is actually legal on the Internet.
  72.         However, in the event that 8-bit or binary mail transport
  73.         becomes a reality in Internet mail, or when this document
  74.                                             ^^^^^^^^^^^^^^^^^^^^^
  75.         is used in conjunction with any other 8-bit or binary-capable
  76.         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  77.         transport mechanism, 8-bit or binary messages should be labeled
  78.         ^^^^^^^^^^^^^^^^^^^
  79.         as such using this mechanism.
  80.  
  81. That is, the MIME standard suggests that 8-bit data be labelled as
  82. such, so that gateways between 8-bit and 7-bit systems can recognize
  83. and encode such data.
  84.  
  85. For example: a WAIS<->email gatway might retrieve a GIF image from a
  86. WAIS server. If the WAIS server stated that the data is type image/gif
  87. and binary encoded, the gateway could base64 encode the data and send
  88. it on its way through SMTP. On the other hand, if the server labelled
  89. the data 7bit text/plain, the gateway could pass it along without
  90. encoding.
  91.  
  92.  
  93.     GOPHER SUPPORT FOR MIME
  94.  
  95. Gopher defines several types of "objects." The basic types are text
  96. files and directories. Other types include various archive formats,
  97. telnet sessions, CSO servers, raw data files, and a few experimental
  98. types.
  99.  
  100. One of the experimental types is 'M' for MIME messages, that is body
  101. parts of type message/rfc-822. I suppose that much of the opposition
  102. to using the MIME body part to model the Gopher object comes from
  103. folks who think that they'd have to put all their data into
  104. message/rfc-822 format.
  105.  
  106. But I didn't suggest we use the MIME message/rfc-822 format for all
  107. Gopher objects: just use _some_ MIME format for all gopher objects.
  108. The fact is, their data is already in a MIME format: text/plain. And
  109. the experimental 'g' (GIF) type is already a MIME type: image/gif.
  110.  
  111. The only Gopher objects that don't fit the MIME system are the ones
  112. that are not data streams at all: telnet sessions, CSO servers, etc. I
  113. don't know how (or if) they fit into the MIME model.
  114.  
  115. There are some Gopher objects that fit the MIME model but are not part
  116. of the MIME standard (yet). For example, the directory listing that
  117. gopher servers send back could be called application/x-gopher for now,
  118. and eventually application/gopher (when it's spec'd out and registered
  119. with the IANA.)
  120.  
  121. The gopher protocol can be enhanced one time to support the myriad of
  122. multimedia data formats by including a content-type field in gopher
  123. listings.
  124.  
  125. The Gopher+ protocol has even more in common with MIME. In Gopher+,
  126. each gopher object has a bunch of ancillary information such as the
  127. maintainer, size, format, etc. A Gopher+ object and its ATTRIBUTES
  128. looks an awful lot like a MIME body part and it's encapsulating
  129. message. It seems a waste to define two competing standards for the
  130. same mechanisms.
  131.  
  132.  
  133.     WAIS SUPPORT FOR MIME
  134.  
  135. A WAIS document looks like a MIME body part too: a sequence of bytes
  136. with a type. The canonical WAIS type is TEXT. And like the type 'M'
  137. support in gopher, somebody hacked in support for a MIME type in WAIS.
  138.  
  139. Again, I suggest that the MIME typing system be used in stead of,
  140. rather than inside, the WAIS typing system. That is, modify the
  141. Document-id Structure Definition so that
  142.  
  143. :type <string>
  144.  
  145. is obsoleted by 
  146.  
  147. :content-type <string> ;; as defined by RFC-1341
  148.  
  149. The only two supported types are TEXT and SRC, whic translate neatly
  150. to text/plain and application/x-wais-src.
  151.  
  152.  
  153.     WWW SUPPORT FOR MIME
  154.  
  155. There was a question on www-talk about non-text data in WWW documents.
  156. It seems clear that using MIME body parts to model WWW documents is a
  157. natural step.
  158.  
  159. The notion of a WWW address should be expanded to what I would call a
  160. reference, which is an address, a content-type, and any identification
  161. information (so that clients can test whether two references point to
  162. the same document.)
  163.  
  164. The WWW client currently infers the content-type from the address. For
  165. the file: scheme, an .html extension implies HTML format -- other wise
  166. text is assumed. Documents from HTTP servers are HTML, which slams
  167. plain text inside SGML if necessary. Documents from Gopher servers are
  168. either plain text or gopher listings. I don't know what WWW clients do
  169. with WAIS documents that aren't text.
  170.  
  171.  
  172.     FROM GLOBAL HYPERTEXT TO GLOBAL HYPERMEDIA
  173.  
  174. The Internet currently serves as the backbone for a global hypertext.
  175. FTP and email provided a good start, and the gopher, WWW, or WAIS
  176. clients and servers make wide area information browsing simple. These
  177. systems even interoperate, with email servers talking to FTP servers,
  178. WWW clients talking to gopher servers, on and on.
  179.  
  180. This currently works quite well for text.  But what should WWW clients
  181. do as Gopher and WAIS servers begin to serve up pictures, sounds,
  182. movies, spreadsheet templates, postscript files, etc.? It would be a
  183. shame for each to adopt its own multimedia typing system.
  184.  
  185. If they all adopt the MIME typing system (and as many other features
  186. from MIME as are appropriate), we can step from global hypertext to
  187. global hypermedia that much easier.
  188.  
  189.  
  190.     READ IT YOURSELF
  191.  
  192. Attached is the text of the MIME RFC. Enjoy.
  193.  
  194. --cut
  195. Content-Description: RFC1341 MIME  (Multipurpose Internet Mail Extensions)
  196. Content-Type: message/external-body;
  197.         access-type=anon-ftp;
  198.         site="thumper.bellcore.com";
  199.         dir="pub/nsb";
  200.         name="BodyFormats.txt";
  201.         size=214081
  202.  
  203. Content-Type: text/plain
  204.  
  205. --cut--